I worked at the University of California Office of the President for 3 years. It was a wonderful job, with an incredibly supportive boss, some brilliant colleagues, and work that mattered deeply. I learned an incredible amount there, but it also took me a while to recover from burnout and sort through the lessons. Here’s what I wrote down over a year ago, in June 2015, after the prompt “What did I learn at UC?” Even with all I’ve learned in the last year, these lessons still feel pretty relevant, so I thought I’d share them:
- Trust other people to do the work, even if they will do it differently. Show them you trust them.
- Building trust is more important than being right.
- Building trust takes listening.
- Showing possibilities is basically magic; no amount of lofty talk gets you as far as a sketch or an example.
- People are better at reacting than creating. Taking on the burden of fighting the empty page can help move things forward when they seem stalled.
- Ownership is tricky and I don’t know quite what makes it work, but I suspect it’s the most important thing; when people own something they give it all they’ve got. When they don’t, they behave unpredictably (i.e. shit on it).
- The person who calls the meeting has to show up on time, and they should know who’s in charge. The person who’s in charge should also know that.
- A few user conversations and real statements trump just about all the “best practices” you can come up with.
- Just because someone suggests something doesn’t mean they need that thing. Stated solutions are often attempts to name the problem.
- The user experience of the people who will need to maintain the content is what will make the project succeed or fail in the long run.
- Cognitive load is a real thing. Overly clever solutions are often prohibitively complex to parse in the long run, even if they make some things easier upfront.
- Don’t let conversations spin without the right people. Figure out who the right people are and get them in the room, or get the information you need to be the right people.
- When something doesn’t get done on time, it’s usually because the person trying to do it doesn’t have enough information — or is trying to do something much more complex than the timeline allowed for. A short conversation will usually help make the task more possible.
- The content design (language and structure) of a page can completely change reading behavior — and make the difference between looking past the content and seeing the words.
- “Phase two” can be a helpful lie for getting to launch, but without a plan and resources, it’s always a lie.
- Work with the users you have, not with the users somebody else has (or with the user you are).
- No one is incompetent or lazy. If it looks that way, you’ve asked them to do the wrong thing or failed to give them enough information.
- Surprised people will surprise you, which is bad news for your project. Keep people posted, bring them up to speed, and don’t assume anyone has filled them in. Ask what they know.
- Show your work. If you make it look easy, you make it look cheap.
- It’s not anyone else’s job to know how to do your job (for instance, to know how websites work). If they don’t understand it, teach them enough to help you.
- Only use “this might be a stupid question…” when it’s definitely not a stupid question.
- Ask what the acronyms stand for.
- Content migration is editing and information architecture.
- Things got how they are for a reason — but sometimes the reason was bad. Understand prior choices, but don’t treat them as sacred.
- Questions are not feature requests.
- Name the trade-offs. People make better decisions when they know they’re making them.
- If you’ve been arguing about a word, phrase, or sentence for more than 5 minutes, try removing it. Does that solve the problem?
- When something seems unmanageable, make it tactile. Even a few minutes of touching paper and moving cards can help wrap your head around something.
- If everything has to be in the nav, the nav is going to get weird.
- People are incredibly good at workarounds, because they’re used to systems that don’t care what they need. If workarounds start showing up before launch, build the damn pathway.
- Rules won’t get followed unless they’re appropriate. Pay attention to norms before you set the rules.
- People want to do things right, but their “right” is more complicated than yours.
- No one else remembers which domain anything belongs on. Literally no one. They don’t even remember the domains. Make shit findable, for internal users too.
- Sometimes the content you forgot about is actually the most important page on the site for a giant group of users everyone took for granted. Ask more questions. Apologize when you break stuff.
- Nobody cares why you got it wrong; explaining sounds defensive. Restate the problem, say you understand its importance, and work toward fixing it.
- These phrases are incredibly valuable: “Oh wow!,” “I did not know that,” “That’s fascinating!,” “Tell me more about that,” “Wow, that sounds like a lot of work,” “Just a minute — this is a lot of great information, and I want to make sure I write it down,” “I’m not sure yet,” and “I want to make sure we come up with something [possible/realistic/useful], so I’m going to get back to you on that.”
- Interruption registers as argument, even when it’s overly-enthusiastic “YES AND” agreement. Just nod and look happy.
- People mostly want to feel seen and heard.
- Images with extreme aspect ratios are scarce. Don’t put a super-wide image on the homepage.
- Don’t hard-code any of the copy. It’s all going to change.
I didn’t edit this list much, so take it with a grain of ¯\_(ツ)_/¯
. Mostly I found myself returning to it and thought it might be useful for you, too.
The most important thing I took from 3 years at UC was this: I got a little better at messing up and being wrong, which I’m increasingly convinced are the most important things to be good at as a writer, designer, and human. That was mostly because of several women who told me what they knew and gave me clear, kind feedback.